| Ticket-ID | Commit | Issue-ID |
|---|---|---|
| KEYCLOAK-17495 | KEYCLOAK-17495 Do not include principal in the reference to broker sessionId | https://issues.redhat.com/browse/KEYCLOAK-17495 |
| Ticket-ID | Commit | Issue-ID |
|---|
| Ticket-ID | Commit | Issue-ID |
|---|---|---|
| KEYCLOAK-16890 | KEYCLOAK-16890: Stored XSS attack on new acct console | https://issues.redhat.com/browse/KEYCLOAK-16890 |
| KEYCLOAK-17033 | KEYCLOAK-17033: Reflected XSS attack with referrer in new account console | https://issues.redhat.com/browse/KEYCLOAK-17033 |
| Ticket-ID | Commit | Issue-ID |
|---|
| Ticket-ID | Commit | Issue-ID |
|---|
| Ticket-ID | Commit | Issue-ID |
|---|
| Ticket-ID | Commit | Issue-ID |
|---|
There is no 9.0.1 tag (anymore).
| Ticket-ID | Commit | Issue-ID |
|---|---|---|
| KEYCLOAK-12242 | KEYCLOAK-12242 KEYCLOAK-12280 | https://issues.redhat.com/browse/KEYCLOAK-12242 |
| KEYCLOAK-12239 | KEYCLOAK-12239 [REL] Upgrade to WildFly 18.0.1 | https://issues.redhat.com/browse/KEYCLOAK-12239 |
The Keycloak maintainers do not announce security fixes (Like for every rule there are exceptions). So to identify the criticality of an update you have to check all the changes in the git repository and try to find out which of them a security fixes. But the Keycloak team makes their JIRA issues private, if they are about security issues. That allows us to correlate git commits with JIRA issues that are private. I miss this list on every Keycloak update. So I decided to do this myself. My goal is to enable others to better decide if they need to update their Keycloak instances.
I do not think so. There could also be other reasons to make an issue private. But I do not know. I am not able to check that. I expect that there will be private issues that are not security issues.
I think so. One could argue that for example every Wildfly update is a security fix in some way. There also might other issues that fixes vulnerabilities, but that are public.
All of them. But test them properly. The .0 releases are huge sometimes and the .1 releases often contain fixes for the previous ones.
As so often there is a problem with the dual-use security dilemma. But I do not publish new research or exploits. In the end I only gather some public information. This can be done by anyone with beginner level bash, git and curl skills. As someone responsible for Keycloak instances I rate the value for me higher than for attackers.
First there is the Threat Model Mitigation part of the official Keycloak docs. This is their "Hardening Guide". Then there is the Keycloak - CNCF Security SIG - Self Assessment. While the submissin process is stuck for a while now the document definitely is worth a read. Third there is the report of a security assessment of Keycloak version 8.0.0 executed by Cure53 funded by REWE digital (Disclaimer: I have been involved in the assessment).